Summary

• TIFF predictor=2 specifies differencing between adjacent same-component samples at the sample's natural bit width. The CPU and GPU code was doing it byte-wise, which drops the inter-byte carry for any sample wider than one byte.
• uint8 was correct (one byte per sample). uint16, int16, uint32, int32 silently produced wrong pixel values.
• Reading a uint16/int16/uint32/int32 predictor=2 TIFF written by libtiff, GDAL, rasterio, or tifffile gave garbage. Writing such a file from xrspatial produced output other libraries decoded as garbage. The internal xrspatial round-trip happened to work because both ends used the same broken arithmetic.
• Fix: dispatch predictor_decode/predictor_encode on CPU and GPU to per-dtype kernels (uint8/16/32/64) that operate on a typed view of the byte buffer with stride = samples_per_pixel.
• Caught by the deep-pass geotiff accuracy audit (follow-up to CPU fp_predictor_decode gives wrong pixels for multi-band predictor=3 TIFFs #1247). Existing tests only covered uint8 multi-sample for predictor=2.

Test plan

• pytest xrspatial/geotiff/tests/test_predictor_multisample.py (33 passed including new GPU+CPU multi-byte cases)
• pytest xrspatial/geotiff/tests/ (533 passed; pre-existing matplotlib recursion failures in test_features plotting tests are unrelated to this change and reproduce on main)
• tifffile interop: write a uint16 predictor=2 file with xrspatial, read with tifffile, and vice versa; both directions match
• GPU CuPy backend exercised on host with CUDA available